The connection of computers and other devices to form networks is well known and wide spread. Such networks provide substantial advantages in enabling computers and their users to communicate and to access and share, resources such as information stores, printers and so forth. A requirement is that an entity such as a computer or other device connected to the network should be aware of or able to identify other network entities with which it can communicate and whose capabilities are available for use.
For relatively small and stable networks, it is known to provide each entity with a network address and to provide that address to other entities. For example, a personal computer may be manually provided with the network address of a printer and set to send all printer jobs to that network address. This technique is however unsuitable for large networks with a very large number of entities connected to the network, or to ad hoc or changeable networks.
A number of protocols or techniques have been developed to enable network entities to identify other entities with desirable characteristics. For example, a personal computer may wish to identify a colour printer able to print a particular type of graphics file. The techniques may broadly be characterised as “look up” techniques in which a directory of entities and their associated capabilities is maintained, and “discovery” in which an entity actively locates or seeks another entity having a desired capability. It is also known to use a combination of “look up” and “discovery” techniques.
Because the terminology in this technical field is not consistent between protocols and applications, the following terms will have the following meaning herein;
“service”—refers to a function or resource provided by a network entity and available over the network to other entities. There clearly need not be a one-to-one relation between services and entities. For example, a combined scanner, printer and fax machine would be a single entity but provide three distinct services.
“entity”—refers to any device or application which provides a service and/or which accesses services over a network. An entity may thus be a physical device, such as a printer, or may be a software application.
“client”—refers to an entity which wishes to access or invoke a service.
“broker”—as a verb means to offer a service which is performed by another network entity, and as a noun refers to any entity which offers a service performed by another entity.
In the “look up” technique, a broker maintains a directory of services available over a network. To find a required service, a client sends a request to the broker identifying the required capabilities. The broker then searches the directory for a service matching the required capabilities and answers the request. Examples of protocols which uses this technique are the lightweight directory access protocol (LDAP) and the CORBA trader service. Such protocols are however computationally heavy and difficult to maintain and install. They do have the advantage that they are able to respond to specific requests for a logical combination of desired capabilities or other criteria. By organising the directory in a hierarchical or other topology, look up protocols may provide scaleability over a wide range of network sizes. As an extreme example, the Internet domain name service (DNS) is a look up system organised as a hierarchy of servers which scale up to the Internet as a whole. Such protocols do not however support the spontaneous addition or removal of entities to and from the network, and are also not appropriate for “ad hoc” networks.
To address these shortfalls, discovery protocols have been devised. In a discovery protocol, an entity advertises its capabilities, for example by multicast over a network, and the capabilities are cached or otherwise recorded by other entities. When a client requires a particular function or resource, it can send a request directly to the service using the cached information. A client may also advertise a request setting out required capabilities, and a service matching those capabilities may respond to the request. As such, no separate directory or broker is required and such a protocol is computationally light and responsive to change in the network.
An example of a discovery protocol is the simple service discovery protocol (SSDP) which has been incorporated into Microsoft Universal Plug-and-Play protocol (UPnP). In SSDP, services multi-cast their capabilities over a allocated SSDP multi-cast channel/port using the HTTP UDP protocol. Services are identified using a universal resource identifier (URI) which identifies the service and its capabilities, and a unique service name (USN). The USN which is a unique identifier such as a universal unique identifier (UUID). SSDP uses both methods of discovery described above. When a service is first connected to the network, it announces its capability and USN which may then be cached by listening entities whilst clients may also transmit a search request using a URI to identify the service type required. Although SSDP is an extremely simple and lightweight protocol, it does not allow clients to search other than by using the various service type identifiers. There is no entity corresponding to a broker and the protocol does not perform any brokering as defined above.
A more sophisticated protocol with discovery, together with a more sophisticated search capability and an optional directory capability is “Salutation”. In the Salutation protocol one or more services are connected to a corresponding Salutation Manager. Each Salutation Manager stores information about services registered with that Salutation Manager. When a client wishes to locate a service having a given set of capabilities, it sends a request to its corresponding Salutation Manager, which contacts other Salutation Managers to identify services requested with those managers which have the required capability. When a service having the required capability is found, the or each Salutation Manager then establishes a service session to connect the client and service. The Salutation Managers are intended to be independent of any particular network protocol, and communications between Salutation Managers across a network are handled by a network-specific transport management layer. As specified in the Salutation architecture specification, a Salutation Manager may store information about services registered in other Salutation Managers to allow the Salutation Manager to maintain a directory of services that are important to local services or clients. It is even envisaged that one Salutation Manager in the network may be designated as a directory responsible for finding and registering all compatible services, and all client requests would be directed towards this Salutation Manager which would act as a broker.
A Java based solution, JINI, is also known which is a combination of look up and discovery techniques. A service, on connection to the network, will locate a look up service. Once the service has identified the look up service, it registers its capabilities with the look up service. A client wishing to identify an appropriate service will send a request to the look up service.
A problem with each technique described above is that the description of each service is essentially static. The information available on each service, whether held by a broker or advertised by the service, itself takes no account of other services available on the network. Where a client wishes to carry out a function which uses a number of resources which are provided by separate services, the client must discover or look up those services separately and invoke them separately.
An aim of the invention is to provide a new or improved lightweight method of brokering services provided over a network.